Typically, a software product is assigned a name-version pair to convey version information about the software product. In most cases, the version label is pre-defined, even before development of the software is completed. For example, Microsoft (“MS”) Windows 2000™ represents a name—version pair, with “Microsoft Windows” representing the name of the software product and “2000” representing the version label conveying the version information about the software product.
FIG. 1 illustrates a representative System Properties dialog box that can be accessed from the Control Panel of a MS Windows operating system (“OS”). FIG. 1 illustrates that the current version of MS Windows installed is 2000. However, the System Properties dialog box provides further version information.
Large-scale software products, such as the MS Windows, usually consist of many modules that work together. Each module is developed separately, debugged separately, and often patched separately. A “service pack” is an example of a regularly issued patch by the Microsoft Corporation. FIG. 1 conveys additional version information to convey to a user that the instant MS Windows 2000 installation has been patched with Service Pack 4. The “5.00.2195” number also conveys specifics regarding the particular MS Windows 2000 installation.
However, patches are often issued outside of the regular service packs. These irregular patches are more difficult to track. Installation of third party software may modify a particular MS Windows installation in ways that current version labels are unable to track. To further compound the problem, users of a processing system may manually alter installation files in a multitude of manners that version labels simply cannot track.
One technique to determine changes to a software product, which version labels do not track, is to execute a file compare DOS command on a target file and a reference file. However, executing a file compare on a large file is a slow process that consumes considerable processor resources. Large-scale software products can contain hundreds, if not thousands, of individual files. Executing a file compare on each individual file to determine which files do not match is unrealistic. In networking environments with centralized databases, the reference file may be located on a centralized database remote from a client system containing the target file. In this scenario, executing a file compare could consume vast amounts of network bandwidth—particularly if many client systems need to compare their local target files against the remote reference file.